IP Media Streaming Service Delivery

ABSTRACT

A method of ordering the delivery of a media stream to a client terminal coupled to an IP network is described. The method comprises identifying, at a user terminal (e.g. a mobile device), destination address information for the client terminal. The user terminal is authenticated to an application server of an IP Multimedia Subsystem network, and the destination address information is sent from the user terminal to the application server. The media stream is then sent to the client terminal. This enables the media to be delivered to the client terminal on the basis of the authentication of the user terminal.

TECHNICAL FIELD

The present invention relates to delivering an IP streaming service andis applicable in particular, though not necessarily, to delivering IPunicast media such as IPTV services.

BACKGROUND

IP television or IPTV is the name given to a range of services whichallow television to be delivered over an IP network. Due to the flexiblenature of an IP network, IPTV will allow for a much more personalisedservice to users, e.g. video-on-demand, with information delivered tousers over unicast IP streams. However, to order and control these userspecific services, the user would normally be expected to use his or herremote control whilst sitting in front of a Set-Top-Box (STB)/TV.Currently the predominant way of controlling these unicast streams is touse the real time streaming protocol (RTSP). RTSP does not specify atransport protocol but may be used, for example, to establish andcontrol real-time transport protocol (RTP) media streams. RTSP is inmany ways similar to the HTTP protocol used to request and exchangeinformation over the web, but is tailored for streaming media such asaudio and video. RTSP allows a client to request particular mediastreams from a streaming server, and specifies commands such as PLAY andPAUSE. RTSP is well suited to the conventional set-top-box use case.

It is expected that users of mobile terminals such as mobile telephoneswill wish to avail themselves of IPTV services. Indeed, this is probablykey to the business models of network operators currently installinghigh capacity cellular networks such as 3G networks. Within cellularnetworks, IPTV is a service which will likely be facilitated by theso-called IP Multimedia Subsystem (IMS). IMS is the technology definedby the Third Generation Partnership Project (3GPP) to provide IPMultimedia services over mobile communication networks (3GPP TS 22.228,TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS29.328 and TS 29.329), although the IMS architecture is such that itsservices can be accessed and controlled via other interfaces, forexample the fixed access network. IMS makes use of the SessionInitiation Protocol (SIP) to set up and control calls or sessionsbetween client terminals, or client terminals and application servers.The Session Description Protocol (SDP), carried by SIP signaling, isused to describe and negotiate the media components of the session.Whilst SIP was created as a user-to-user protocol, IMS allows operatorsand service providers to control user access to services and to chargeusers accordingly.

It will be appreciated that IMS and RTSP have traditionally beenconsidered as alternative approaches for the establishment and controlof unicast streaming sessions. Whilst IMS provides a mechanism forcontrolling QoS and charging, as well as transcoder negotiation, RTSPsupports trickplay and basic video-oriented commands.

A number of systems are currently on the market which allow a user tocontrol a STB remotely over the Internet. These include LocationFreeTV™from Sony Corporation and Slingbox™ from Sling Media. Both of thesesystems allow a user to instruct the delivery of media from the home STBto a client terminal (e.g. a STB or a television in a hotel room inwhich a user is staying).

SUMMARY

Current commercially available systems such as LocationFreeTV andSlingbox are designed to allow a user of a remote terminal, for examplean Internet connected device such as a mobile telephone, PDA, or laptop,to order the delivery of media from the home STB to the remote terminal.They are not designed to allow the user to order the delivery of mediato some terminal other than the one currently being used, be it in thehome or elsewhere. Even if this were possible, it would necessarilyinvolve the routing of media through the home STB which would result inquality of service and scalability issues.

It is desirable, for example, to allow a user to make use of a mobiletelephone to order the delivery of media to a terminal in the user'shotel room or other current location. It is further desirable for theuser to order the delivery of media to a such a terminal even if it isnot IMS enabled.

In accordance with one aspect of the present invention there is provideda method of ordering the delivery of a media stream to a second clientterminal coupled to an IP network. The method comprises identifying, ata first client terminal, destination address information for the secondclient terminal. The first client terminal is authenticated to anapplication server of an IMS network, and the destination addressinformation is sent from the first client terminal to the applicationserver. The media stream is delivered to the second client terminal.

This means that the media stream can be delivered to the second clientterminal on the basis of the authentication and/or authorisation of thefirst client terminal to the application server. The user of the firstclient terminal can pay for the media via his subscription. The secondclient terminal need not be IMS enabled (although it will be appreciatedthat the invention also applies to the situation where the second clientterminal is IMS enabled).

The destination address information may include the IP address and portnumber of the second client terminal, and/or the IP address and portnumber of any gateway, such as a RGW, through which the second clientterminal is coupled to the IP network.

The authentication of the first client terminal to the applicationserver preferably includes an authentication of a user identity module(e.g. SIM/UICC card) associated with the first client terminal.

The authentication of the first client terminal to the applicationserver may include a token identity handshake. In one embodiment, theauthentication of the first client to the application server includes anauthentication and/or authorisation of the second client terminal. Oncethe second client terminal has been authorised to the applicationserver, then the second client terminal can request delivery of themedia stream directly, but the authorisation will have come from thesubscription of the first client terminal. Alternatively, the mediastream may be delivered to the second client terminal in response to aRTSP service request sent from the first client terminal to theapplication server.

In one embodiment, a RTSP Uniform Resource Locator (URL) of theapplication server may be sent to the first client terminal, and thisRTSP URL can then be passed on to the second client terminal. A sessionidentity (generated by the application server) may be passed from thefirst client terminal to the second client terminal and used by thesecond client terminal to request delivery of the media stream. Forexample, the session identity may be identified by the first clientterminal as a result of a RTSP SETUP procedure. This session identitymay then be used by the second client terminal in a RTSP PLAY messagesent towards the application server.

In a further alternative, if the second client terminal is IMS enabled,a SIP INVITE message may be sent from the application server to thesecond client terminal in response to a service request sent from thefirst client terminal to the application server.

The first client terminal may preferably be coupled to the IP WANnetwork via a cellular access network. The second client terminal may becoupled to the IP network via a fixed access network. In one embodiment,a reservation of resources for delivery of the media stream to thesecond client terminal over the fixed access network is initiated by anIMS message, preferably a SIP INVITE message including the destinationaddress information, sent from the first client terminal towards theapplication server.

Preferably the first client terminal establishes communication with thesecond client terminal in order to identify the destination addressinformation. This communication may be established using a localwireless network such as a WLAN or Bluetooth, although it will beappreciated that other means of communication (e.g. infra-red, cable)are also possible.

The media is preferably a unicast media such as IPTV, but it will beappreciated that other media may also be ordered. For example, mediasuch as broadcast TV and games may also be provided.

In accordance with another aspect of the present invention there isprovided an application server for use in an IMS to control the deliveryof media to client terminals coupled to an IP network. The applicationserver comprises a receiver for receiving, from a first client terminalin the IP Multimedia Subsystem, destination address information for asecond client terminal coupled to the IP network. The application serveralso comprises authentication means for authenticating the first clientterminal, and a processor and transmitter for arranging delivery of themedia from a media source to the second client terminal. The mediasource may be any suitable media source, for example an nPVR, avideo-on-demand server, etc.

In accordance with another aspect of the present invention there isprovided a user terminal arranged in use to communicate with anapplication server of an IP Multimedia Subsystem. The user terminalcomprises a receiver for receiving destination address information froma second client terminal, and a transmitter/processor/receiver forsending the destination address information to said application server,authenticating the user terminal to the application server, andinstructing the application server to arrange delivery of media to thesecond client terminal. The user terminal preferably comprises an HTTPinterface for communicating with the application server, and a wirelessinterface for communicating with the remote terminal.

In accordance with another aspect of the present invention there isprovided a method of delivering a media stream to a client terminal. Themethod comprises authenticating a user terminal to an application serverand sending address details of the client terminal from the userterminal to the application server.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically an IPTV topology architecture;

FIG. 2 illustrates schematically an IPTV AS of the network illustratedin FIG. 1;

FIG. 3 illustrates schematically a mobile station of the network of FIG.1;

FIG. 4 illustrates a process for remotely ordering delivery of a mediastream according to a first embodiment of the invention;

FIG. 5 illustrates a process for remotely ordering delivery of a mediastream according to a second embodiment of the invention; and

FIG. 6 illustrates a simplified version of the process of FIG. 5.

DETAILED DESCRIPTION

A brief description of the architecture and operation of the IPMultimedia Subsystem (IMS) will aid in understanding embodiments of thepresent invention.

Call/Session Control Functions (CSCFs) operate as SIP proxies within theIMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF(P-CSCF) which is the first point of contact within the IMS for a SIPclient (typically residing in a client terminal); the Serving CSCF(S-CSCF) which provides services to the user that the user is subscribedto; and the Interrogating CSCF (I-CSCF) whose role is to identify thecorrect S-CSCF and to forward to that S-CSCF a request received from aSIP terminal via a P-CSCF.

A user registers with the IMS using the specified SIP REGISTER method.This is a mechanism for attaching to the IMS and announcing to the IMSthe (IP) address at which a SIP user identity can be reached. The userreceives a unique Uniform Resource Identifier (URI) from the S-CSCF tobe used when it initiates a dialog. In 3GPP, when a SIP client performsa registration, the IMS authenticates the user (using the AKAprocedure), and allocates an S-CSCF to that user from the set ofavailable S-CSCFs. Whilst the criteria for allocating an S-CSCF is notspecified by 3GPP, these may include load sharing and servicerequirements. It is noted that the allocation of an S-CSCF is key tocontrolling (and charging for) user access to IMS-based services.

During the registration process, it is the responsibility of the I-CSCFto select an S-CSCF if one is not already selected. The I-CSCF receivesthe required S-CSCF capabilities from the home network's Home SubscriberServer (HSS), and selects an appropriate S-CSCF based on the receivedcapabilities. (It is noted that S-CSCF allocation is also carried outfor a user by the I-CSCF in the case where the user is called by anotherparty, and the user is not currently allocated an S-CSCF.) When aregistered user subsequently sends a session request (e.g. a SIP INVITE)to the IMS, the request will include the P-CSCF and S-CSCF URIs so thatthe P-CSCF is able to forward the request to the selected S-CSCF. Thisapplies both on the originating and terminating sides (of the IMS). (Fora terminating call the request will include the P-CSCF address and theUser Equipment (UE) address.)

Within the IMS service network, Application Servers (ASs) are providedfor implementing IMS service functionality. ASs provide services toend-users in an IMS system, and may be connected either as end-pointsover the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the3GPP defined ISC interface. In the latter case, Initial Filter Criteria(IFCs) are used by the S-CSCF to determine which ASs should be “linkedin” during a SIP Session establishment. Different IFCs may be applied todifferent call cases. The IFCs are received by the S-CSCF from an HSSduring the IMS registration procedure as part of a user's User Profile(UP). Certain ASs will perform actions dependent upon subscriberidentities (either the called or calling subscriber, whichever is“owned” by the network controlling the AS). For example, in the case ofcall forwarding, the appropriate (terminating) application server willdetermine the new terminating party to which a call to a givensubscriber will be forwarded.

As well as having SIP interfaces (ISC or Mr), an AS can have one or morenon-SIP interfaces. In particular, the Ut interface allows an AS tocommunicate directly with a client terminal using, for example, the RTSPor HTTP protocols.

FIG. 1 presents an overview of the IPTV/IMS architecture illustratingthe apparatus/functionality provisioned within a customer premisesnetwork (CPN) 1 (e.g. a home or a hotel room) and by a Mobile Station(MS) 2, which are attached respectively to a fixed access network 4 anda cellular access network 5 and visited operator IMS network 6. A TV 10attached to a set top box (STB) 9 is located in the CPN 1. The STB 9communicates with the fixed access network either directly or via aResidential Gateway (RGW) 13. A home operator provides an IPTV serviceprovider 3 and home IMS network 19. Network elements of interest hereare:

MTRX—Media Transmission/Reception Part 7,8; The “traditional” Set TopBox functionalities in an STB 9, for example reception of MPEG2 and/orMPEG4 streams and conversion of such streams for delivery to a TV 10.The MTRX 8 in the MS 2 should be IMS enabled. The MTRX 7 in the STB 9need only be IP enabled.IMOD—Identity and IMS Module 12; The part of an IMS enabled Set Top Boxthat contains the basic IMS service logic and the ISIM. The IMOD isimplemented in the MS, enabling remote access to TV services.WIFI—A wifi application 20, 21 (e.g. DLNA (Digital Living NetworkAlliance) or UPnP (Universal Plug and Play)) enables the MS 2 tocommunicate directly with the STB 9.AS—Application Server 14; The function that interacts between the MS(and other IMS user devices) and the IPTV video servers. The AS alsoreceives and processes HTTP and RTSP messages and sends media to the STB9.Video Streaming Server—the video streaming server 15. This is the sourceof unicast (streaming) media.VoD—Video-on-demand (control) server 16. This server controls access toand playout from the distributed video unicast servers.nPVR—network-based Personal Video Recorder 17. This server allowssubscribers to store media, e.g. programmes, within the network.Playback is controlled via the IPTV AS.EPG—Electronic Programme Guide 18. The EPG server stores details ofcurrently available and upcoming media. A subscriber typically downloadsthe EPG via the IPTV MW AS and uses this to select or programme mediadelivery (available at the VoD/video unicast servers.

The MTRX entities will be present within STBs that are used to accessthe IPTV service. In addition, and as illustrated in the FIG. 1, theMTRX entity 8 and an IMOD 12 are present within the Mobile Station (MS)2 or client terminal, which could for example be a cellular telephone.It will be appreciated that the MS may be present within an IMS network6 of an operator that is not the operator of the IPTV service.

FIG. 2 illustrates schematically the functional elements within the IPTVAS 14. These include a receiver 22 coupled to the Home operator IMSnetwork 19 and a processor/transmitter 23 which can be coupled to thefixed access network 4. FIG. 3 illustrates schematically the functionalelements within the MS 2, namely a transmitter/receiver 24 forcommunicating with the STB 9, a transmitter 25 for transmitting servicerequests to the IPTV AS, and a receiver 26 for receiving signalinginformation from the IPTV AS.

A process for allowing a user of the MS 2 to order the delivery of mediato some third party terminal (STB) 9, located with the CPN 1, will nowbe described with reference to FIG. 4

FIG. 4 illustrates a process flow according to a first embodiment of theinvention. In step S1, the MS2 obtains the IP address, Port number andcapability of the STB 9. This is typically carried out over a wirelessconnection, for example using DLNA or UPnP. However, any connectionwhich enables the required exchange of information may be used. If theSTB communicates the fixed access network via a RGW (not shown in FIG.4), then the external IP address and port number of the RGW are alsoobtained by the MS 2.

In step S2, the MS 2 contacts its home IMS network 19 via the visitedIMS network 6. The MS 2 is authenticated by the home IMS network 19 ashaving a subscription in that network, and authorised to make a purchasefrom the IPTV service provider 3. Step 2 is carried out using SIPsignaling.

In step S3, the MS 2 is authenticated to the IPTV service provider 3.The IP address and port number of the STB 9 and/or RGW 13 may beprovided to the IPTV service provider 3, so that they can be used asauthentication/authorisation credentials by the STB later in theprocedure. In a further alternative, the IPTV service provider 3 maygenerate and locally store a specific token identity. This tokenidentity is later handed over from the MS to the STB to allow the STB toreceive the requested service upon a service request message. As aresult of steps 2 and 3, the MS 2 is able to arrange for the delivery ofmedia from the IPTV service provider 3 to the STB 9, and this media canbe paid for via the subscription of the MS 2 with his home IMS network19.

In step S4, the MS 2 contacts the IPTV service provider (with whom it isnow authenticated) via the visited mobile network 6 and requests detailsof the URL or source IP and Port number of the entity that willeventually provide the media. It may also request an EPG, which may bedisplayed to the user by the MS 2, or may be transferred (as shown instep S5) from the MS to the STB 9 to be displayed on the television 10.The MS 2 may also pass the IP address and Port number of the IPTVservice provider to the STB 9 at this stage, together with the tokenidentity referred to in step S3 (if obtained). Step S4 may be carriedout using HTTP.

In step S6, once the user has selected the IPTV service that he wouldlike to receive, the MS 2 contacts the IPTV service provider via thevisited mobile network 5 to reserve necessary resources for delivery ofthe desired IPTV service. The MS 2 provides the external IP address andPort number of the STB 9 (and/or RGW 13) to the IPTV service provider 3(if this has not already been done as part of the token exchange of step3). Step 5 is carried out using SIP.

As part of this process, in step S7 a media plane set-up for thefixed-access network may be carried out. This may be triggered in thevisited IMS network by the external IP address of the RGW 13 or the STB9. The IMS network 16 recognises that the appropriate route for deliveryof IP data to the RGW 13 is over the fixed access network 4, and themedia plane is set up accordingly. Step S7 is carried out using SIP.

In one embodiment, step S6 is initiated by a SIP REQUEST message beingsent from the MS 2 towards the home IMS network 19. The REQUEST messageincludes the external IP address of the RGW, and this is used by thevisited IMS network 6 to reserve the required resources over the fixednetwork 4 in step S7.

In step S8, the MS 2 requests delivery of the IPTV service to the STB 9.This may be accomplished, for example, by a SIP INVITE message from theMS 2, which is mapped by the AS in the IPTV service provider's networkto RTSP DESCRIBE and SET-UP messages before they are further relayed tothe Video streaming server. An RTSP PLAY is then sent from the MS. The“sink” IP address and port number are those of the STB 9, eitherdirectly or via the RGW 13. Alternatively, the delivery of the IPTVservice may be jointly requested by the MS2 and the STB 9. In this case,the SIP INVITE message is send from the MS 2 as just described, but theRTSP PLAY originates from the STB 9.

In step S9, the IPTV service is delivered from the IPTV service providerto the STB 9 over the fixed access network 4. The user will pay for theservice as a result of his subscription to the home IMS network 19.

FIG. 5 shows an alternative embodiment of the invention. In thisembodiment, once an IPTV service is selected, it is requested in stepS8″ purely from the STB 9. This may, for example, be carried out usingan RTSP DESCRIBE, SET-UP or PLAY message. In this example, it will benoted that no resources are reserved for the IPTV service, and nor areinteractivity services coupled with the IPTV service, such as chat andmessaging, facilitated.

In a further alternative embodiment (not shown), the STB 9 or TV 10 mayalso be IMS enabled. If this is the case, then in step 3 of FIG. 4 theMS 2 identifies the IP address and port number of the STB 9 to the IPTVservice provider. At step 5, the MS 2 sends a service request message tothe IPTV service provider 3, as a result of which the IPTV serviceprovider sends a SIP INVITE message towards the STB 9, and SIPnegotiations may be conducted directly between the IPTV service provider3 and the STB 9 to arrange delivery of the media. However, the user willstill be charged via his subscription as the negotiations must followfrom the initial authentication to the home IMS network.

In a further embodiment, the MS obtains the RTSP URL of the AS at theIPTV service Provider. This may also be passed to the STB 9. A specificsession identity may be handed over to the STB from the MS after theRTSP SETUP has been carried out (i.e. during S5 shown in FIG. 6). Thissession identity may then be included in the STB RTSP PLAY command senttowards the IPTV service provider.

FIG. 6 illustrates a high-level and simplified arrangement in which anMS 2 contacts an IPTV AS 14 via a proxy 61 in an IMS network 19, inorder to order IPTV services. FIG. 6 is a combination of FIG. 4 and FIG.5 and facilitates all benefits of FIG. 4, but with the addition that theSTB issues the final RTSP PLAY message as in FIG. 5. The sequence ofevents is as follows:

ST1. UPnP: Get IP address & Port number & capability of IPTV STB 9.ST2. UPnP: Get external IP address & Port number and IPTV addressmapping.ST3. SIP: INVITE (IP address and port number of RGW 13 attached).ST4. SIP: INVITE (IP address and port number of RGW 13 attached).ST5. RTSP: DESCRIBE, SET-UP (IP address and port number of RGW 13attached).ST6. UPnP/DLNA: “PLAY” Session ID from IPTV ServerST7. RTSP: PLAY RTSP URL and Session ID from IPTV Server. (Sink IPaddress/port number are those of RGW 13. These are mapped to IPTV in RGW13.)ST8. RTP: Media delivery

Thus the present invention enables the user to order the delivery ofIPTV to any IP enabled device, since the IMS negotiation and resourcereservation to be carried out between the MS and the IPTV serviceprovider. The service can be provided anywhere or at any time. There isno constraint on the uplink of a broadband connection, since thesignaling is carried out by the mobile device. The media delivery pathcompared to previously known solutions is greatly reduced. The homenetwork need not be complex: it simply has to be configured to receivethe IPTV services.

Furthermore, the “interactivity” which is one of the key benefits withIMS based IPTV, can be handled via the MS instead of via the IPTV screen(which is the case where an IMS-enabled STB is used). This is trueespecially if the signaling sequences shown in FIG. 4 and FIG. 6 arefollowed.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiments withoutdeparting from the scope of the present invention. For example, thesteps described above show a simple environment, but there is no reasonwhy the invention cannot also be applied to more complex environmentsinvolving firewalls and Network Address Translators (NATs). These may bein the home or in the operators' networks.

Furthermore, the above embodiments have been described in the context ofa mobile station subscribed to a cellular network and a set top boxsubscribed to a fixed access network. It will be appreciated that othervariants are possible. Indeed, the complexity may be reduced if fewernetworks are involved.

In addition, all embodiments have been described with referencespecifically to the delivery of IPTV. It will be appreciated that theinvention applies equally to all services provided or managed by theoperator. Other examples include broadcast TV, gaming and other similarapplications.

It will also be appreciated that person-to-person interactivityservices, such as chat and messaging, tied to the media delivery andenabled through IMS, may be operated on a device other than the IPTVscreen. For example, interactivity services may still be operated viathe display screen of the MS.

1. A method of ordering the delivery of a media stream to a secondclient terminal coupled to an IP network, the method comprising:identifying, at a first client terminal, destination address informationfor the second client terminal; authenticating the first client terminalto an application server of an IP Multimedia Subsystem network; sendingthe destination address information from the first client terminal tothe application server; and delivering the media stream to the secondclient terminal.
 2. The method of claim 1, wherein the destinationaddress information includes the IP address and port number of thesecond client terminal.
 3. The method of claim 1, wherein thedestination address information includes the IP address and port numberof a Residential Gateway through which the second client terminal iscoupled to the IP network.
 4. The method of claim 1, wherein theauthentication of the first client terminal to the application serverincludes an authentication of a user identity module associated with thefirst client terminal.
 5. The method of claim 1, wherein theauthentication of the first client terminal to the application serverincludes a token identity handshake.
 6. The method of claim 1, whereinthe authentication of the first client terminal to the applicationserver includes authorizing the second client terminal to theapplication server.
 7. The method of claim 1, wherein a RTSP UniformResource Locator of the application server is sent to the first clientterminal.
 8. The method of claim 7, wherein the RTSP Uniform ResourceLocator of the application server is passed from the first clientterminal to the second client terminal.
 9. The method of claim 1,wherein a session identity is generated in the application server, sentto the first client terminal and passed from there to the second clientterminal, and used by the second client terminal to control delivery ofthe media stream.
 10. The method of claim 1, wherein the media stream isdelivered to the second client terminal in response to an IMS INVITEmessage and RTSP PLAY message sent from the first client terminal to theapplication server.
 11. The method of claim 1, wherein the media streamis delivered to the second client terminal in response to an IMS INVITEmessage sent from the first client terminal and an RTSP PLAY messagesent from the second client terminal to the application server.
 12. Themethod of claim 1, wherein the media stream is delivered to the secondclient terminal in response to a RTSP DESCRIBE, SET-UP and PLAY from thesecond client terminal to the application server.
 13. The method ofclaim 1, wherein a SIP INVITE message is sent from the applicationserver to the second client terminal in response to a service requestsent from the first client terminal to the application server.
 14. Themethod of claim 1, wherein the first client terminal is coupled to theIP network via a cellular access network.
 15. The method of claim 1,wherein the second client terminal is coupled to the IP network via afixed access network.
 16. The method of claim 15, wherein a reservationof resources for delivery of the media stream to the second clientterminal over the fixed access network is initiated by an IMS messagesent from the first client terminal towards the application server. 17.The method of claim 16, wherein the IMS message sent towards theapplication server is a SIP INVITE message including the destinationaddress information.
 18. The method of claim 1, wherein the first clientterminal establishes communication with the second client terminal inorder to identify the destination address information.
 19. The method ofclaim 18, wherein the communication established between the first clientterminal and the second client terminal is established using a localwireless network.
 20. The method of claim 1, wherein the media is IPTVmedia.
 21. An application server for use in an IP Multimedia Subsystemto control the delivery of media to client terminals coupled to an IPnetwork, the application server comprising: a receiver for receiving,from a first client terminal in the IP Multimedia Subsystem, destinationaddress information for a second client terminal coupled to the IPnetwork; an authentication circuit for authenticating the first clientterminal; and a processor and transmitter for arranging delivery of themedia from a media source to the second client terminal.
 22. Theapplication server of claim 21, wherein the destination addressinformation includes the IP address and port number of the second clientterminal or, if the second client terminal is coupled to the IP networkvia a Residential Gateway, the IP address and port number of saidResidential Gateway.
 23. The application server of claim 21, wherein theauthentication circuit is arranged to authenticate a user identitymodule associated with the first client terminal.
 24. The applicationserver of claim 21, wherein the authentication circuit is arranged tocarry out a token identity handshake.
 25. The application server ofclaim 21, wherein the authentication circuit is arranged to authorizethe second client terminal as a result of the authentication of thefirst client terminal.
 26. The application server of claim 21 whereinthe receiver is arranged to receive a RTSP service request from thefirst client terminal, and wherein the processor is configured toarrange delivery of the media to the second client terminal in responseto the RTSP service request.
 27. The application server of claim 21wherein the processor is configured to send a SIP INVITE message towardsthe second client terminal in response to a service request receivedfrom the first client terminal.
 28. The application server of claim 25,wherein the receiver is arranged to receive an RTSP PLAY command fromthe second client terminal, and wherein the processor is configured toarrange delivery of the media to the second client terminal in responseto the RTSP PLAY command.
 29. A first client terminal arranged in use tocommunicate with an application server of an IP Multimedia Subsystem,the first client terminal comprising: a receiver for receivingdestination address information from a second client terminal; and atransmitter/processor/receiver for sending the destination addressinformation to said application server, authenticating the first clientterminal to the application server, and instructing the applicationserver to arrange delivery of media to the second client terminal. 30.The terminal of claim 29, further comprising an HTTP interlace forcommunicating with the application server.
 31. The terminal of claim 29,further comprising a wireless interlace for communicating with thesecond client terminal.
 32. (canceled)